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REMARKS 

Claims 1-54 were pending in the application at the time the Final Office Action was 
mailed. The applicants responded on June 22, 2004 to the Final Office Action of April 22, 
2004, and the Examiner issued an Advisory Action on July 27, 2004. The Advisory Action 
did not indicate whether the amendments of June 22, 2004 were entered. Accordingly, the 
applicants make the same amendments in this response, and incorporate their prior 
arguments here by reference. Moreover, the applicants amend claims 1-2, 4, 6, 7-8, IS- 
IS, 21, and 42 in this response to further clarify aspects of the applicants' technology and 
correct typographical errors. Accordingly, claims 1-54 are pending. 

The Final Office Action rejected claims 1-54 as follows: 

A) Claims 1-8, 10, 12-15, 18-19, 21-22, 24-32, 36-39, 42^6, and 48-53 were 
rejected as being unpatentable under 35 U.S.C. § 102(e) over U.S. Patent No. 6,237,025 
("Ludwig"). Thus, all independent claims were rejected as being unpatentable over 
Ludwig. 

B) Claims 9, 11, 23 were rejected as being unpatentable under 35 U.S.C. 
§ 103(a) over Ludwig in view of U.S. Patent No. 6,600,725. 

C) Claims 16-17 and 33-35 were rejected under 35 U.S.C. § 1 03(a) over Ludwig 
in view of U.S. Patent No. 6,343,313. 

D) Claims 20, 40-41, 47, and 54 were rejected under 35 U.S.C. § 103(a) over 
Ludwig in view of U.S. Patent No. 6,606,112. 

The applicants respectfully traverse these rejections. 

The applicants' technology provides an application program interface ("API") of a 
multipoint processing module, as discussed thoroughly throughout the applicants' 
specification. An API may be used by other software components such as applications 
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and software modules to receive functionality and control the multipoint processing 
module. As an example, an application may use aspects of the API to receive 
videoconferencing functionality using computing devices and associated peripherals, and 
another application may use aspects of the API to receive teleconferencing functionality. 
By using the API, an application developer can provide the functionality received from the 
multipoint processing module without providing extensive program logic that would 
otherwise be required to provide the functionality. These applications may be provided by 
different software vendors who choose to use the API provided by the multipoint 
processing module. 

Ludwig is directed to a "multimedia collaboration system that integrates separate 
real-time and asynchronous networks." (Ludwig, Abstract.) "These capabilities are 
achieved by exploiting a variety of hardware, software and networking technologies in a 
manner that preserves the quality and integrity of audio/video/data and other multimedia 
information." (Id.) Ludwig provides an integrated solution, including hardware, software, 
and an application with a user interface. 

At least two important differences exist between Ludwig's technique and the 
applicants' technology. First, Ludwig neither teaches nor suggests an API as recited by 
independent claims 1, 13, and 21. Second, Ludwig neither teaches nor suggests a 
multicast bridging terminal as recited by independent claim 42. 

The applicants can find no mention of an extensibility mechanism in Ludwig that 
provides an API. An API, as suggested above, enables multiple software components, 
such as applications, to utilize functionality exposed by the API. As an example, the 
MICROSOFT WINDOWS operating system API enables multiple applications to use 
functionality provided by the operating system to create or modify files. Similarly, the 
applicants' technology provides an API for collaboration software applications to be 
designed that can use the API to send or receive collaboration-related information. 
Independent claims 1,13, and 21 are amended by this response to more particularly recite 



[41 826-8771 -U SOOOO/S L042470. 1 29] 



19 



Application No.: 09/539,026 

this feature. For example, claim 1 is amended to recite "exposing at least one application 
program interface by the multipoint processing module." Ludwig, in contrast, describes an 
integrated solution that does not allow other applications to control or use its functionality. 
Therefore, Ludwig has no reason to describe an API as claimed by the applicants. 

Independent claim 42 recites creating a multicast bridging terminal. A multicast 
bridging terminal bridges clients using different types of control signaling. As an example, 
one client may use H.323 signaling, and another client may use a different variety of 
signaling. The Examiner refers to Ludwig at 37:1-65 as teaching a multicast bridging 
terminal. (Final Office Action, page 14.) This section of Ludwig discusses multi-party 
videoconferencing. Multi-party videoconferencing does not always necessitate a multicast 
bridging terminal, and Ludwig makes no mention of bridging two different types of control 
signaling in the cited section. The applicants can find no mention of a multicast bridging 
terminal using two different types of control signaling elsewhere in Ludwig. Accordingly, at 
least claim 42 cannot be rejected under 35 U.S.C. § 102(e) over Ludwig. 

In view of the foregoing, the claims pending in the application comply with the 
requirements of 35 U.S.C. § 112 and patentable define over the applied art. A Notice of 
Allowance is, therefore, respectfully requested. If the Examiner has any questions or 
would believe that a telephone conference would expedite prosecution of this application, 
the Examiner is encouraged to call the undersigned at (206) 359-6478. 



PERKINS COIE LLP 
P.O. Box 1247 

Seattle, Washington 981 1 1 -1 247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorney for Applicant 




Respectfully submitted. 




Maurice J. Pirio 

Registration No.: 33,273 
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